（原題: What Should We Teach New Software Developers? Why? ）
![[article image]](What_Should_We.large.jpg "whiteboard eraser")
産業界のニーズによりよく応えるために計算機科学教育に対して根本的な変革が必要です。
日本語訳: 里田 和敏
計算機科学（訳注: Computer Science = CS ）はソフトウェアシステム開発の 中心になければいけません。そうでなければ、私たちは各個人の感覚や経験則に 頼らざるをえず、挙句に性能も劣り信頼性も劣るシステムを不必要に高いコストを かけて開発し保守することになってしまいます。私たちは産業界での実業務の 改善を考慮に入れるよう、教育における変革を必要としています。
多くのところで、計算機科学教育と産業界が必要とするものとの間には 隔たりがあります。次のやりとりを考えてください:
有名な CS 教授 (誇らしく): 「われわれはプログラミングを 教えるのではない。計算機科学を教えるのだ。」
業界経営者: 「彼らはほんのちょっとのプログラムだって やりとげられやしない。」
多くの場合、彼らはどちらも表層的なレベルにとどまらず正しいことを 言っています。 ありきたりのプログラマを育てるだけのことは学界の仕事ではありませんし、 業界のニーズは「熟練した高度な思想家」や「科学者」だけに向けられる ものではありません。
別の CS 教授: 「私はまったくコードを書きません。」
別の業界経営者: 「私たちは CS 卒業生を雇いません。 CS 卒業生に物理を教えるよりも、物理学者にプログラムを教えるほうが 簡単だからです。」
どちらにも一理ありますが、しかし理想的な世界では、どちらも根本的に 心得違いとなるでしょう。教授は、自分が実践しない（そして多くの場合、 一度も実践したことがない）、結果として理解していないものを教えることは できないという点で間違っており、いっぽう業界経営者のほうは、ソフトウェアの 品質に対する要求が物理学者（そして CS について未熟なその他）でも 賄えるほど馬鹿らしいくらい低く設定されているときにだけしか 正しくありません。言うまでもなく、私は計算機科学をも習得するために 多大な努力を注ぎ込んだ物理学者を指してはいません—そういった技能の 組み合わせは私の理想の中にあります。
CS 教授 (学生について): 「彼は業界の仕事に就くことになったよ。」
別の CS 教授: 「残念。彼にはとても見込みがあったのに。」
この隔たりは多くの問題の根底にあり、それらを改善しようとする試みを 困難にします。
業界は計算機科学の卒業生に（少なくとも彼らのキャリアの初期には） ソフトウェアを組むことを望みます。そのソフトウェアはしばしば長く生き続ける コードベースの一部となり、高い信頼性要求の組み込み或いは配布されるシステムに 使われます。しかし、多くの卒業生は趣味的な活動の他には本質的に ソフトウェア開発の教育や訓練を受けてはいません。詳しくいえば、ほとんどは プログラミングを宿題を片付けるための最低限の労務と見ており、 システマティックなテスト、保守、文書化、他の人によるそのコードの利用を 含む、より広い視点に立つことはほとんどありません。また、多くの学生が ある授業で学んだことと別の授業で学んだこととを結びつけるのに失敗します。 そのため、アルゴリズムやデータ構造やソフトウェア工学において高い点数を 取っているにもかかわらず、オペレーティングシステムの授業ではデータ構造や アルゴリズムやソフトウェアの構造をまったく無視して解答をひねり出す学生を 私たちはよく見かけます。その結果は、まずい動作をする保守不能な失敗作です。
多くの人にとって、「プログラミング」は無節操なハックと他の人の ライブラリの（行われることについてごくぼんやりとした理解だけでの） 呼び出しとの不可思議な組み合わせとなってしまっています。「保守」や 「コードの品質」への思慮は典型的には無視されるか不十分にしか 理解されません。業界において「システム」を理解し「ソフトウェアを設計できる」 卒業生を見つけることの難しさは広く見られ、現実を反映しています。
ソフトウェアに対して不満を言うことはよくある気晴らしですが、多くの ソフトウェアはこの十年で、まさしくその前の十年二十年のように、改良されて きました。不幸なことに、それらの進歩は人々の努力やコンピュータのリソースの 面で莫大なコストを払ってもたらされています。基本的に、私たちは無数の 実行時検査レイヤの追加や大量のテストによって、信頼できない部品から十分に 信頼できるシステムを作り上げる方法を学んできました。コード自体の構成は 時に変化してきましたが、常に良い方向にではありません。しばしば、 たくさんのソフトウェアのレイヤや、設計に良く見られる入り組んだ 依存関係は、個人が—どんなに有能であっても—完全にシステムを 理解することを妨げます。これは将来的な災いを示唆します。すなわち、 私たちは自分のシステムの重大な側面を理解せず、評価することすらできない ということです。
もちろん、肥大化して不可解なシステムを作らせる圧力に抵抗してきた システム作成者もいます。私たちは、コンピュータ化された飛行機が 墜落しなかったり、電話が動作したり、メールが即座に届いたりしたときには 彼らに感謝してもいいでしょう。ソフトウェア開発を成熟して信頼できる原理や ツールや技法の集まりとするためのその努力に対して、彼らは賞賛を受けるに 値します。残念ながら彼らは少数派であり、ほとんどの人々の気持ちや考えは ブロートウェア（訳注：肥大化したソフトウェア）が支配しています。
同じように、理論と業界の実態との乖離に対して戦ってきた教育者もいます。 彼らも賞賛と積極的な支援を受けるに値します。実のところ、私の知る 教育機関はすべて実務的な経験をねらった教程を持っていて、その教程を 成功させるために自分の生活をささげてきた教授もいます。しかし俯瞰して みると、感心できなくなります—ひとつふたつのプロジェクトや インターンシップは良いスタートですが、バランスの取れたカリキュラムに 向けた包括的な取り組みの置き換えとはなりません。「CS」よりも「IT」や 「ソフトウェア工学」というラベルを好むことは観点の違いを示すの かもしれませんが、問題というものは新しい環境に移れば微妙に違った姿で また現れるという嫌な面を持っているものです。
業界と学界についての私の描写は戯画に近いものですが、少し経験のある 人なら誰でも、そこに反映された現実の部分に覚えがあるだろうと確信して います。私の視点は、今は学界（工学校の CS 学科）で 6 年間勤めた、 産業界の研究者および管理者（ AT&T ベル研究所での 24 年間と、そのうち 部長としての 7 年間）としてのものです。私は多くの旅行をし、毎年数十の （主に U.S. の）会社の技術的で経営的立場の人たちと真剣な議論をします。 私はこの、大学が生み出すものと業界が望むものとの食い違いを、 CS の 可能性とコンピューティング産業との両方についての悪い兆しと見ています。
コンピュータの利用に決定的に依存している多くの 組織が危険なほど技術的スキルに乏しくなっています。
では私たちに何ができるでしょうか？業界は最新のツールと技法の中で 十分に訓練された「開発者」を雇うことを望むでしょうが、その一方で学界の 最大の狙いはより多くより優れた教授を生み出すことです。改善のためには これらの理想がよく調整されなければなりません。業界に入ろうとする卒業生は ソフトウェア開発について適切な理解を備えておくべきですし、業界は新しい アイディアやツールや技法を取り入れるためのより良い仕組みを 発達させなければなりません。半人前のプログラマが害を起こすのを防ぐように 図られた文化の中に優れた開発者を送り込むのは、その新しい開発者が斬新で 優れた何をするのも制限されてしまうので、不毛なことです。
スケールについての話もしておきましょう。多くの産業的システムは 数百万行のコードから成りますが、その一方で学生は千行よりも大きな プログラムを一度も書くことなく最高の CS 教程を優等で卒業することが できます。すべての主要な産業的プロジェクトには幾人かの人員が参加しますが、 多くの CS 教程はチームワークを妨げるように気をつけて個人的な成果を 評価します。この現実に応じて、多くの組織は開発者の能力への依存を 最小化するようにツールや技法や言語や操作手順を単純化することに 注力しています。これは全員を最小公分母へ押し下げることになるため、 人的才能や努力を無駄にしてしまいます。
業界は試験済みで間違いの無いツールや技法を頼りにしたいのですが、 しかしまた「銀の弾丸」「変化をもたらす大発見」「キラーアプリ」等々の 夢にも耽っています。彼らは、コードの品質についての詳細に悩まされるには 偉過ぎる少数の「夢想家」に率いられ、最低限の技術を持ち交換可能な 開発者たちでやりくりしていけることを望んでいます。これは、基本的な ツール（プログラミング言語やオペレーティングシステムなど）の選択に ついての頑なな保守傾向や、（教育や配備のコストを最小化する）単一化への 願望を導きます。さらにこれは、巨大な私有の、相互に互換性の無いインフラの 造成につながります。開発者がアプリケーションを作るのを可能にするためには 基本的なツールを超えた何かが必要になり、プラットフォーム提供者は 開発者を囲い込むための何かを、その基本的なツールの共通性に関わらず 欲しがります。報奨システムは、大企業によるたくらみと短期的な結果との 両方を促進します。結果的なコストは、新しいプロジェクトが失敗する割合が そうであるように、驚異的なものとなります。
業界の現実—そしてそのほかの同様の妨げ—に面して、 学界はその最善を尽くしながらも内に閉じ篭ってしまっています: 似たような 考えの人から成る小さなグループへの隔離で対応できる現象について注意深く 調査したり、頑丈な理論的基盤を構築したり、理想化された問題について 完璧な設計や技法を作り出したり。古臭いスタイルで書かれた巨大なコードベースを 対象とする私有のツールはこのモデルに合いません。業界と同様、学界も相応な 報奨の構造を作っています。これらはすべて、よく描き出された学術的対象にある 重工業コースの着実な進歩と完全に合っています。このため、学界での成功は 業界の要求に対して円孔方木となり噛み合わず、業界は特殊化されたインフラの 開発コストとともに教育コストも負わねばなりません。
いつも「業界が開発者に相応の給料を払えば問題はなくなる」と言い出す人が います。それは助けにはなるでしょうが、同じ種類の仕事により多くを 支払うことはあまり多くを助けることになりません。可能な代替として、業界は より優れた開発者を必要とします。ソフトウェア開発を半人前の交換可能な 働き手を並べた組み立てラインとする考えは根本的に欠陥をもっており無駄な ものです。それは最も有能な人をその分野から押し出し、学生の参入を 思いとどまらせます。この悪循環を断ち切るため、学界は適切な技能を持った 卒業生をもっと送り出さなければなりませんし、業界はそれらの技能を生かすための ツールや技法やプロセスを受け入れなければなりません。
「計算機科学（訳注: コンピュータサイエンス）」とは嫌な紛らわしい 言葉です。 CS は主として コンピュータに関するのではありませんし、本来科学ではありません。 むしろコンピュータの利用者や計算を伴った仕事や 思考（「アルゴリズム的で定量的な思考」）に関するものです。それは科学や 数学や工学の側面を、多くはコンピュータを使って組み合わせます。 CS に 身を置くほとんどすべての人にとって、それはひとつの応用分野です— 応用から隔てられた「純粋な CS 」は概して不毛なものです。
アプリケーションを作る CS の人とアプリケーションを作る何か別の 分野（医学や物理学など）のプロフェッショナルとを区別するものは 何でしょうか？答えは「 CS のコアに精通していること」に違いありません。 その「コア」とは何になるでしょうか？それは既成の CS カリキュラムの 多くを含むでしょう—アルゴリズム、データ構造、マシンアーキテクチャ、 プログラミング（根本的なもの）、いくらかの数学（主に証明に基づく 定量的な論法を教えるためのもの）、システム（オペレーティングシステムや データベースなど）。それらの知識を結びつけ、より大きな問題の扱い方を 知るため、すべての学生がいくつかのグループプロジェクトを完成させなければ なりません（これを基本的なソフトウェア工学と呼んでもいいでしょう）。 理論的なこととのバランスが取れていることが肝心です。 CS は原則と 理論だけではありませんし、コードをいじくりまわすだけでもありません。
このコアは明らかにコンピューティングの分野全体よりも遥かに コンピュータ指向です。そのため、 CS の中での特化（たとえば画像、 ネットワーク、ソフトウェアアーキテクチャ、人と機械との関わり、 セキュリティ）を加えること無しには誰も計算機科学者と呼ばれるべきでは ありません。しかし、それでも十分ではありません。計算機科学の実践は 本来実用的で学際的であり、すべての CS プロフェッショナルは何か他の 分野（たとえば物理学、医療工学、歴史学、会計事務、フランス文学）を 副専攻したのと同等のものを持っているべきです。
経験のある教育者は言うでしょう: 「しかしこれは不可能だ！どんな学生だって その全てを４年で修めることはできやしない。」これらの教育者は正しいことを 言っています。つまり何かを譲る必要があります。私の提案は、 計算機科学者として開業する資格を得る最初の学位を、最後の１～２年を 加えた学士号ではなく修士号—そして一体として計画された修士号—とするべきだ、 というものです。研究をするつもりの人なら普通は博士号を目指すでしょう。
多くの教授が反発するでしょう: 「プログラムする時間なんて無いよ！」 しかしながら、ソフトウェアのプロになろうとする学生を教える教授なら その時間を作らなければならないでしょうし、制度側は彼らが プログラムすることに報いる方法を見出さねばならないと思います。 CS の究極のゴールは優れたシステムを作る助けになることです。外科医学を 教えるのに何年も患者を診ていない誰かをあなたは信じるでしょうか？鍵盤に 触れたことが無いピアノの先生をどう思うでしょうか？ CS 教育は学生を 必要な読学の先の、完全なシステムに対するその適用に精通し、コードの美学に ついての正しい理解を得るところまで導かなければなりません。
私は「プロフェッショナル」という言葉を使っています。それは多くの意味や 暗示を含む言葉です。医学や工学のような分野ではそれは免許制度を示します。 免許制度はとても難しく心動かす話題です。どうあれ、私たちの文明は ソフトウェアに依存しています。本質的には誰でもが個人的な好みや 企業のポリシーに基づいてコードの根幹部分を変更できることが妥当なこと でしょうか？もしそうなら、それは５０年先も妥当であるでしょうか？ 数百万の人が依存するソフトウェアが保証の無い部品からなることが妥当なこと でしょうか？現実としての問題は、免許制度によって強制される プロフェッショナリズムは知識やツールや技法の大きな共有体の存在に依存する ということです。免許を持つ設計士は、ある建物が公認の技法と資材を使って 建設されていることを保証できます。広く認められた CS 能力（先に示した ような）の枠組みがないうちは、ソフトウェアアプリケーションについてそれを どうやって行うのかわかりません。現代においては、免許試験（あるいは 現実的には、医療部局（訳注: medical boards アメリカ合衆国の各州に 配置される医療機関）のようにいろいろな副専攻のテストの集まり）を作る 人の集まりをどう選んだらよいのかすらもわかりません。
このギャップを埋めるために業界には何ができるでしょうか？「業界」や 「業界のニーズ」を描き出すことは学界について語ることよりもずっと困難です。 今日においては、学界はいくらか標準的な構造と、その目的を達成するための いくらか標準的な方法を備えています。業界はずっと広く分かれています: 大きいか小さいか、商業的か非営利か、システム構築の方法について 洗練されているか平均的か、などなど。そのため、私は療法の処方を始めること すらできません。しかしながら、私はこの学界と業界とのギャップに直接関連する ひとつの見解を持っています: コンピュータの利用に決定的に依存している多くの 組織が危険なほど技術的スキルに乏しくなっています:
業界経営者: 「技術的専門家の能力を内部調達することは生き残りに 直結します。」
組織的な記憶と新しい才能を補充し育てるためのインフラ無しではどんな 組織も成功し続けることはできません。ソフトウェア開発に関心のある学者との 共同制作を増やすことは双方にとって実りが多いかもしれません。共同の研究と 単なる訓練課程を超えた生涯続く学習への注視とはこの中の主要な役割を 果たし得るでしょう。
私たちは改善しなければなりません。そうしない限り、私たちのインフラは 軋み、肥大化し、リソースを吸い取り続けるでしょう。ゆくゆくは、何か 予測できない破滅的な形でどこかが壊れてしまうことにもなるでしょう （インターネットルーティング、オンライン銀行取引、電子投票、電力網の 制御を想像してください）。とりわけ、学界と業界とのギャップを双方での 変化を起こすことで縮めなければなりません。私の提案は、最終的には ソフトウェア作成についての免許制度を、少なくともそれを作り出す CS プロフェッショナルを目標としながら、 CS 教育の構造を特化と応用範囲とを コアに加えたものに基づいて定義することです。これは技術的専門家にとって 生涯的な産学協同に注視することと手をとりあっていくかもしれません。
Bjarne Stroustrup (bs@cs.tamu.edu) は テキサス州カレッジステーションにあるテキサス A&M 大学で 工学科の計算機科学教授の議長をしています。
DOI: http://doi.acm.org/10.1145/1629175.1629192
著作権は著者が保持しています。
The Digital Library は Association for Computing Machinery が公開しています。 Copyright © 2010 ACM, Inc.
Published with permission from the Association for Computing Machinery.
この文書は Communications of the ACM の 2010 年 1 月版 Vol 53, No.1 に 掲載された記事（原文）の 日本語訳で、著者 Bjarne Stroustrup さん、 および Association for Computing Machinery の許可のもとで公開しています。
メールによる突然の申し出なのでダメ元だったのですが、寛大で素早い対応を していただきました。
誤訳・誤字脱字の指摘や翻訳の改良など、日本語訳についての連絡は 里田 和敏 (k_satoda@f2.dion.ne.jp) へ おねがいします。